Upgrade checklist updates #967
Conversation
[skip ci]
dacook
force-pushed
the
upgrade-updates
branch
from
32186d7 to
7ba0b7b
Compare
| @@ -17,9 +19,10 @@ Checklist based on general guide https://github.com/openfoodfoundation/ofn-insta | |||
| - [ ] DNS: add temporary domain (eg `prod2.openfoodnetwork.org`) | |||
|
|
|||
| ### config | |||
| - [ ] Add temporary name to `inventory/hosts` | |||
| - [ ] Add temporary name to `inventory/hosts` (suggest doing this on separate branch) | |||
There was a problem hiding this comment.
I'm wondering about this temporary host name. I don't think it's temporary. Don't we want to be able to identify a unique host like prod4.openfoodnetwork.org.au which is providing the site openfoodnetwork.org.au?
There was a problem hiding this comment.
Agreed, I think the unique hostname is very helpful. I'm not sure, but we should be able to use that in the hosts definition, rather than the primary domain.
This is distinct from the app domain which is set in host_vars (domain and certbot_domains). The guide suggested also using the temporary domain there but I found it caused more problems than it was worth.
I feel like this list needs rewriting again but I won't do that while it's not fresh in my mind.
| @@ -9,6 +9,8 @@ assignees: '' | |||
|
|
|||
| Checklist based on general guide https://github.com/openfoodfoundation/ofn-install/wiki/Migrating-a-Production-Server | |||
|
|
|||
| Tip: find/replace to set up most commands ready to go, eg: `x_prod` -> `ca_prod` | |||
There was a problem hiding this comment.
I wonder if we should use easy to replace example names like old_server and new_server which could be prod or staging. Some of the guide just refers to x instead of x_prod as well. It would be good to make this consistent.
There was a problem hiding this comment.
That makes sense. Although in some places it's actually referring to the domain name (eg host_vars/x/config.yml) so that could have its own keyword.
| - [ ] `db_transfer.yml` ~3min | ||
| - [ ] `sudo systemctl stop postgres` (ensure other integrations no longer touch it) | ||
| - [ ] `transfer_assets.yml` just in case | ||
| - [ ] `sudo systemctl stop postgresql` (ensure other integrations no longer touch it) | ||
|
|
||
| ### switchover: new server | ||
| - [ ] `sudo systemctl restart puma; sudo systemctl start sidekiq redis-jobs` |
There was a problem hiding this comment.
Sidekiq is disabled at this point. We have to enable it first before we can start it. But I personally would probably do it staggered:
- Start puma and check with hosts file.
- Start sidekiq and check log file.
- Then install proxy forwarding.
There was a problem hiding this comment.
How much time did you need for testing? If it's short, maybe we could do it during maintenance mode which would enable us to then switch over straight away. It would save us all the work of transferring data twice and resetting in between.
There was a problem hiding this comment.
I agree that would be much quicker, I just found that it was never straightforward enough to be confident that everything would work first go, so I preferred a more conservative approach.
There was a problem hiding this comment.
But I personally would probably do it staggered:
That's a good idea. I did those checks in the 'testing' stage, so skipped it here. But you could totally do it that way too.
Some more updates to the upgrade checklist and readme.
I'd like to update the process further and simplify it.. but haven't got time for that.